We shouldn't remove the old configuration names: if someone has used localparam_style and parameter_style in their configuration it will suddenly fail as it doesn't exist anymore.

Instead, we should have not only the new regex names, but also the old names, which then select a regex.
So someone can set localparam_style_regex, but they can also say localparam_style=ALL_CAPS, which could be considered a name for a regex; So if such value has been set, we then then can set the upper case regex.

Do you have a preference on how it should handle if both localparam_style and localparam_style_regex are set with valid values?

Maybe have ParameterNameStyleRule::Configure return an absl::InvalidArgumentError() noting the user should use one or the other.

On second thought, maybe ignore localparam_style_regex unless the user sets localparam_style to some value (say "regex") so the user has to explicitly enable that feature.

Just looking at the code again, localparam_style is an OR'd list of things, so when the rule is configured it would have OR multiple regex's together, potentially including the users regex, simple enough.

Anyway, let me know if you have a preference (or better solution).

Ah, yes, the OR-ing part, I didn't think of it: yes that should then assemble a (foo)|(bar) kindof regex.

But with OR-ing in place, we can assemble all the regex from localparam_style with the localparam_style_regex if both of them are given in the lint configuration.

Probably good to have a test for all these situations; for that, you could have public functions that return the const RE2 * for each regex

const RE2 *localparam_style_regex() const { return localparam_style_regex_.get(); }

, so that it is easy to write a test that verifies that the returned value is re != nullptr and the re->pattern() matches the expectation after having called Configuration().

This example shows how hard it is to actually use if just the defaults would be needed; so making it possible to set the parameter_style:CamelCase will not only be backwards compatible, but also much more usable while still keeping the possibility open to actually use the regex.